بی‌سبب نیست که CSS اینقدر برام جذاب شده بود. به نظر میاد اسراییل از طریق تحلیل شبکه اجتماعی و شبیه سازی، این‌قدر شناخت عمیق و معتبری از چارت سازمانی حزب‌الله پیدا کرده.

Computational social science:
یک رشته بین‌رشته‌ای است که از روش‌های محاسباتی و داده‌محور برای مطالعه پدیده‌های اجتماعی استفاده می‌کند. این رشته ترکیبی از علوم اجتماعی، علوم کامپیوتر و تحلیل داده‌های بزرگ است. برخی از کاربردها و اهداف اصلی آن عبارتند از:

۱. تحلیل شبکه‌های اجتماعی: بررسی روابط و تعاملات بین افراد و گروه‌ها در مقیاس بزرگ.

۲. مدل‌سازی رفتار اجتماعی: ایجاد مدل‌های کامپیوتری برای پیش‌بینی و درک رفتارهای جمعی.

۳. تحلیل متن و زبان: استفاده از پردازش زبان طبیعی برای تحلیل محتوای رسانه‌های اجتماعی و سایر منابع متنی.

۴. مطالعه دینامیک‌های اجتماعی: بررسی چگونگی گسترش اطلاعات، ایده‌ها و رفتارها در جوامع.

۵. سیاست‌گذاری مبتنی بر شواهد: استفاده از داده‌های بزرگ برای تصمیم‌گیری‌های سیاسی و اجتماعی.

۶. بررسی افکار عمومی: تحلیل نظرات و دیدگاه‌های مردم در مقیاس وسیع.

۷. پیش‌بینی روندهای اجتماعی: استفاده از الگوریتم‌های یادگیری ماشین برای پیش‌بینی تغییرات اجتماعی.

این رشته به محققان و سیاست‌گذاران کمک می‌کند تا درک عمیق‌تری از پدیده‌های پیچیده اجتماعی به دست آورند و راه‌حل‌های مؤثرتری برای چالش‌های اجتماعی ارائه دهند.
---
تحلیل شبکه‌های اجتماعی در مطالعه گروه‌های پارتیزانی و چریکی کاربرد مهمی دارد. یک مثال قابل توجه در این زمینه، مطالعه‌ای است که بر روی شبکه‌های ارتباطی گروه‌های چریکی در کلمبیا انجام شده است.

در این مطالعه، محققان از داده‌های مربوط به ارتباطات و تعاملات بین اعضای گروه‌های چریکی FARC (نیروهای مسلح انقلابی کلمبیا) استفاده کردند. آنها با استفاده از تکنیک‌های تحلیل شبکه اجتماعی، ساختار سازمانی و الگوهای ارتباطی این گروه را مورد بررسی قرار دادند.

برخی از نتایج و کاربردهای این تحلیل عبارتند از:

1. شناسایی رهبران کلیدی: با تحلیل مرکزیت در شبکه، افرادی که نقش محوری در انتقال اطلاعات و هماهنگی عملیات داشتند، شناسایی شدند.

2. درک ساختار سلسله مراتبی: تحلیل شبکه نشان داد که FARC علیرغم ظاهر غیرمتمرکز، دارای ساختار سلسله مراتبی مشخصی است.

3. شناسایی نقاط آسیب‌پذیر: با تحلیل پل‌های ارتباطی در شبکه، نقاطی که حذف آنها می‌توانست به قطع ارتباط بین بخش‌های مختلف گروه منجر شود، مشخص شدند.

4. الگوهای جذب نیرو: تحلیل شبکه نشان داد چگونه گروه از روابط خانوادگی و اجتماعی برای جذب اعضای جدید استفاده می‌کرد.

5. تأثیر بر استراتژی‌های مقابله: این تحلیل‌ها به نیروهای امنیتی کمک کرد تا استراتژی‌های مؤثرتری برای مقابله با گروه طراحی کنند.

6. پیش‌بینی واکنش‌ها: با درک ساختار شبکه، محققان توانستند واکنش‌های احتمالی گروه به اقدامات دولت را پیش‌بینی کنند.

این مثال نشان می‌دهد چگونه تحلیل شبکه اجتماعی می‌تواند به درک عمیق‌تر از ساختار و عملکرد گروه‌های پیچیده مانند سازمان‌های چریکی کمک کند و اطلاعات ارزشمندی برای تصمیم‌گیری‌های استراتژیک فراهم آورد.

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

سلام.
بابت کم کاری این مدت کانال عذر می‌خوام. واقعیتش من چند سال گذشته فضای لارج اسکیل رو تو اکوسیستم JVM تجربه کرده بودم و بعد بیشتر درگیر بیزنس‌های اسمال و مدیوم بودم. اخیرا مجدد به فضای نسبتا لارج با رویکرد مدرن میشه گفت برگشتم و این باعث شده مجبور بشم خیلی چیزای جدید رو که لازمه یاد بگیرم و خیلی چیزارو که قبلا صرفا از دور دیده بودم رو باهاش درگیر شم. امیدوارم به زودی پروسه تولید محتوا برای کانال رو از سر بگیرم.

* بخشی از مستند زیبای «تهران انار ندارد»
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

به عنوان مهندس گاهی تکنولوژی، متدلوژی یا رویکردی را برای حل مساله پیشنهاد می‌کنیم، نه به این دلیل که بهترین راه‌حل برای مساله است بلکه می‌خواهیم در رزومه‌مان باشد. چنین تصمیمی به ندرت نتایج خوبی در پی خواهد آورد.
بهترین راه اینه که نیازمندی‌های بلندمدت مشتری رو بر نیازمندی‌های کوتاه مدت خودمون ارجح‌تر بدونیم.

‎#TIP-01

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

ساده سازی پیچیدگی‌های ذاتی و کم کردن پیچیدگی‌های تصادفی
- پیچیدگی ذاتی، به دشواری‌های ذاتی یک مسئله اشاره دارد که بدون از دست دادن جزئیات مهم نمی‌توان آن را ساده‌تر کرد. برای مثال، کنترل ترافیک هوایی یک کشور به خودی خود یک مسئله پیچیده است، زیرا باید موقعیت دقیق، سرعت، جهت و مقصد هر هواپیما را در لحظه ردیابی کرد تا از برخوردها جلوگیری شود. همچنین، برنامه‌ریزی زمان‌های پرواز و مدیریت تغییرات آب و هوایی هم به پیچیدگی ذاتی این مسئله اضافه می‌شود.
    
- پیچیدگی اتفاقی به بار اضافی اشاره دارد که توسط سیستم‌ها یا چارچوب‌هایی که برای حل پیچیدگی ذاتی ساخته شده‌اند، اضافه می‌شود. در مثال ترافیک هوایی، سیستم‌های قدیمی کنترل ترافیک هوایی یک نمونه از پیچیدگی اتفاقی است. این سیستم‌ها که برای مدیریت پیچیدگی‌های ترافیک هوایی ایجاد شده‌اند، به مرور زمان قدیمی شده و انعطاف‌پذیری خود را از دست داده‌اند، به‌طوری‌که به‌روزرسانی آن‌ها بسیار دشوار شده است و لایه‌های غیرضروری به مشکل اصلی اضافه کرده‌اند.
    
 
گاهی اوقات، توسعه‌دهندگان به دلیل چالش‌برانگیز بودن مسائل پیچیده، به سمت پیچیدگی جذب می‌شوند، اما این میل می‌تواند باعث ایجاد سیستم‌های بیش از حد پیچیده و دارای پیچیدگی اتفاقی شود. چالش برای معماران سیستم این است که چارچوب‌ها و راه‌حل‌هایی را انتخاب کنند که این پیچیدگی اتفاقی را به حداقل برسانند و روی کدی تمرکز کنند که مستقیماً به حل مشکل اصلی کسب‌وکار کمک می‌کند، نه اینکه ساختار را با راه‌حل‌های بی‌جهت پیچیده کنند.
 
برای دستیابی به این هدف، توصیه‌ها عبارتند از:
 
1. انتخاب چارچوب‌هایی که در عمل موثر بودن خود را اثبات کرده‌اند به جای طرح‌های نظری صرف.
2. ارزیابی درصد کدی که فقط به ارتباط بین کاربر و سیستم می‌پردازد و مستقیماً مشکل اصلی را حل نمی‌کند.
3. با دقت انتخاب کردن راه‌حل‌های ارائه شده توسط فروشندگان، زیرا این راه‌حل‌ها گاهی بیشتر پیچیدگی اتفاقی را افزایش می‌دهند تا اینکه آن را برطرف کنند.
 
در نهایت، وظیفه معمار سیستم این است که پیچیدگی‌های ذاتی را به‌درستی مدیریت کند و از افزودن پیچیدگی اتفاقی جلوگیری کند تا راه‌حل‌های بهینه، قابل نگهداری و انعطاف‌پذیر ایجاد شوند.
 
"پیچیدگی ذاتی در هر مسئله وجود دارد، اما پیچیدگی اتفاقی از راه‌حل‌های اضافه و غیرضروری ناشی می‌شود. وظیفه معماران سیستم این است که بدون افزودن پیچیدگی غیرضروری، راه‌حل‌هایی ساده و کارآمد برای مسائل پیچیده طراحی کنند."
#TIP-02

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

اهمیت ارتباطات و دینامیک‌های بین‌فردی در موفقیت پروژه‌های نرم‌افزاری قابل کتمان نیست و که تکنولوژی به تنهایی معمولاً دلیل شکست‌ها نیست. در اینجا چند نکته کلیدی آمده است:
 
1. مردم به جای تکنولوژی: موفقیت یا شکست یک پروژه معمولاً به دینامیک تیم و نحوه ارتباط آن‌ها بستگی دارد، نه به فناوری خاصی که انتخاب شده است.
    
2. گفتگو به عنوان یک ابزار: برقراری گفتگوهای باز و محترمانه می‌تواند به حل مسائل موثرتر از درگیری‌ها کمک کند. ایجاد محیطی که در آن اعضای تیم احساس شنیده شدن و ارزشمندی کنند، بسیار مهم است.
    
3. مدیریت احساسات: نزدیک شدن به بحث‌ها با ذهنیت آرام و مثبت بسیار حیاتی است. نشانه‌های غیرکلامی می‌توانند تأثیر زیادی بر نحوه دریافت پیام‌ها داشته باشند.
    
4. تعیین اهداف مشترک: همکاری برای تعیین اهداف مشترک می‌تواند تمرکز را از رفتارهای فردی به سمت موفقیت جمعی هدایت کند و همکاری و مسئولیت‌پذیری را تقویت کند.
    
5. فرصت‌های یادگیری: برخورد با چالش‌ها به عنوان فرصت‌هایی برای رشد می‌تواند به بهبود روابط و نتایج بهتر پروژه‌ها منجر شود.
    
 
در نهایت، تأکید بر عنصر انسانی در توسعه نرم‌افزار است، جایی که ارتباطات مؤثر و همکاری می‌تواند اغلب مسائل را که تنها با تکنولوژی حل نمی‌شوند، برطرف کند.

#TIP-03

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

ارتباطات پادشاه و بندگانش شفافیت و رهبری است!

معماران نرم‌افزار برای موفقیت پروژه باید با تیم‌های خود ارتباطی روشن و رهبری مؤثر داشته باشند. معمولاً زمانی که معماران به‌جای تعامل، از بالا دستورات خود را به توسعه‌دهندگان تحمیل می‌کنند، اختلافات زیادی به‌وجود می‌آید و پروژه از اهداف اصلی فاصله می‌گیرد.
ارتباط مؤثر نیازمند سادگی و وضوح است؛ به‌جای اسناد طولانی و پیچیده، استفاده از ابزارهای ساده‌ای مانند نمودارهای اولیه و جلسات غیررسمی روی وایت‌برد پیشنهاد می‌شود. این روش‌ها امکان تغییرات سریع را فراهم می‌کنند و ایده‌ها را واضح‌تر انتقال می‌دهند. ثبت این جلسات با عکاسی و اشتراک آن‌ها در ابزارهایی مانند ویکی نیز پیشنهاد می‌شود تا همه اعضای تیم بتوانند به اطلاعات دسترسی داشته باشند.
علاوه بر این، معماران باید نقش خود را به‌عنوان رهبر بپذیرند و به‌جای پنهان‌کردن تصمیمات از تیم، آن‌ها را در فرآیندهای کلیدی شرکت دهند. این شفافیت باعث می‌شود که تصمیمات معماری اعتبار بیشتری پیدا کنند و همه اعضای تیم (توسعه‌دهندگان، تیم QA، تحلیل‌گران و مدیران پروژه) در جهت اهداف پروژه هم‌سو باشند.


#TIP-04

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

معماری برنامه تعیین‌کننده اصلی عملکرد آن است و این مسئله ممکن است بدیهی به‌نظر برسد، اما تجربه نشان می‌دهد که بسیاری از معماران نرم‌افزار به‌اشتباه تصور می‌کنند با تغییر یک فناوری یا نرم‌افزار زیرساختی، می‌توان مشکلات عملکردی برنامه را حل کرد. به عنوان مثال، ممکن است یک محصول جدید به‌خاطر تبلیغات و بنچمارک‌ها وعده بهبود عملکرد ۲۵ درصدی بدهد، اما اگر مشکل اصلی در معماری ناکارآمد برنامه باشد، این بهبود اندک تأثیر چندانی نخواهد داشت.

تیم‌های پشتیبانی و نویسندگان مطالب مدیریت عملکرد نیز معمولاً توصیه می‌کنند که با تنظیماتی مثل تخصیص حافظه یا اندازه استخر اتصالات، عملکرد برنامه را بهبود بخشید. اما اگر معماری و نحوه استقرار برنامه برای بار کاری مورد انتظار طراحی نشده باشد، این تنظیمات نمی‌توانند عملکرد مطلوب را به ارمغان بیاورند. در چنین شرایطی، به‌جای تکیه بر تنظیمات جزئی، نیاز به بازنگری و اصلاح معماری داخلی یا استراتژی استقرار وجود دارد.

در نهایت، همه برنامه‌ها و محصولات با محدودیت‌های اساسی محاسبات توزیع‌شده و ظرفیت‌های محدود سخت‌افزار مواجه‌اند. به همین دلیل، بهبود عملکرد و مقیاس‌پذیری نیازمند بازطراحی‌های دقیق و هوشمندانه است و نمی‌توان با تغییر ساده نرم‌افزار یا تنظیمات زیرساختی به آن دست یافت.
عملکرد عالی در نرم‌افزار، نتیجه معماری اصولی و طراحی هوشمندانه است، نه تکیه بر تغییر برندها و تنظیمات جزئی. بهبود واقعی یعنی بازنگری عمیق در ساختار و استراتژی.

#TIP-05

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

در قابلیت‌های درخواستی، به دنبال _ارزش_ بگردید.
داستان هواپیمای F-16 فالکون مثال خوبی است؛ جایی که نیاز اصلی "فرار از نبرد" بود، نه دست‌یابی به سرعت ۲ تا ۲.۵ ماخ که از نظر فنی بسیار چالش‌برانگیز بود. با درک نیاز اصلی، تیم طراحی توانست یک هواپیمای سبک و چابک طراحی کند که با هدف واقعی مأموریت هماهنگ بود و نیازی به سرعت بالا نداشت.

این مفهوم در توسعه نرم‌افزار، به‌ویژه در روش‌های چابک (Agile)، به معنای همکاری و اطمینان از این است که هر ویژگی به یک هدف واقعی خدمت می‌کند. وقتی مشتریان ویژگی خاصی را درخواست می‌کنند، فهمیدن علت این درخواست به تیم کمک می‌کند تا راه‌حل‌هایی بسازد که ارزش واقعی ایجاد کنند. این رویکرد می‌تواند به راه‌حل‌های نوآورانه‌ای منجر شود که نیازهای کاربران را بهتر برآورده می‌کنند و منابع را بهینه‌تر مصرف می‌کنند.

تأکید بیانیه چابک بر "همکاری به‌جای قرارداد" تیم‌های توسعه را تشویق می‌کند تا با مشتریان تعامل بیشتری داشته باشند و نیازهای آن‌ها را دقیق‌تر بررسی کنند. از طریق کارگاه‌ها و بحث‌های هدفمند، تیم توسعه به مشتریان کمک می‌کند تا اهداف خود را بدون ورود زودهنگام به مباحث فنی مشخص کنند؛ چرا که پرداختن به جزئیات فنی ممکن است تمرکز را منحرف کند. با تمرکز بر حوزه مشتری، تیم می‌تواند نرم‌افزاری را توسعه دهد که به نیازهای واقعی پاسخ دهد، مهم‌ترین ویژگی‌ها را اولویت‌بندی کند و از پیچیدگی‌های غیرضروری جلوگیری کند.
وقتی مشتری ویژگی خاصی درخواست می‌کنه، به جای تمرکز روی "چی"، به "چرا" دقت کنیم. درک نیاز واقعی به تیم کمک می‌کنه راه‌حل‌های بهتری بسازه که ارزش بیشتری خلق کنه


#TIP-06

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

معماران نرم‌افزار که از موقعیت‌های فنی به نقش‌های رهبری منتقل می‌شوند نکات مهمی را باید در نظر داشته باشند. در این نقش‌ها، ارتباط مؤثر به اندازهٔ مهارت‌های فنی اهمیت دارد. نکات کلیدی برای بهبود مهارت‌های ارتباطی در این نقش عبارتند از:
 
1. قدرت حضور را درک کنید: وقتی برای صحبت با گروهی می‌ایستید، دینامیک جلسه به نفع شما تغییر می‌کند. این کار به طور طبیعی اقتدار و اعتماد به نفس شما را نشان می‌دهد و باعث می‌شود دیگران کمتر صحبت شما را قطع کنند و بیشتر به حرف‌هایتان توجه کنند.
    
2. استفاده از زبان بدن و ارتباط چشمی: زبان بدن و ارتباط چشمی در انتقال مؤثر ایده‌ها اهمیت دارند. ایستادن به شما کمک می‌کند تا با تعداد بیشتری از افراد ارتباط چشمی برقرار کنید و با استفاده از حرکات دست، پیام خود را بهتر منتقل کنید.
    
3. تأثیر روی صدا و بیان: وقتی ایستاده صحبت می‌کنید، حالت صدا، حجم، سرعت و لحن شما به طور طبیعی تغییر می‌کند. این تغییرات باعث می‌شوند نکات مهم را با تأثیر بیشتری به مخاطب منتقل کنید و پیام خود را واضح‌تر بیان کنید.
    
 
به عنوان یک معمار نرم‌افزار، برای انتقال بهتر ایده‌ها، هنگام صحبت با گروه بایستید. ایستادن به شما اقتدار و اعتماد به نفس می‌بخشد، زبان بدن و ارتباط چشمی را بهبود می‌دهد و تأثیرگذاری پیام شما را دو برابر می‌کند.

#TIP-07

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

خرابی در تمامی اجزای یک سیستم پیچیده اجتناب ناپذیر است؛ از سخت‌افزار و نرم‌افزار گرفته تا خطاهای انسانی و محدودیت‌های شبکه. تاکید اصلی بر مهندسی تاب‌آوری است؛ یعنی طراحی و پذیرش فعالانه سیستم‌هایی که توانایی واکنش مناسب در برابر خرابی‌ها را دارند.
 
سخت‌افزار قابل اعتماد نیست، بنابراین ما از افزونگی (Redundancy) استفاده می‌کنیم تا در برابر خرابی‌های سخت‌افزاری بقا داشته باشیم، اما این کار احتمال وجود حداقل یک خرابی در هر زمان را افزایش می‌دهد. نرم‌افزار نیز خطاپذیر است، و از آنجا که برنامه‌های ما از نرم‌افزار تشکیل شده‌اند، مستعد خطا هستند. برای نظارت بر خرابی‌ها، نرم‌افزارهای نظارتی را اضافه می‌کنیم، اما این نظارت هم از جنس نرم‌افزار است و خود می‌تواند دچار خرابی شود.
 
انسان‌ها هم مرتکب اشتباه می‌شوند، بنابراین برای کاهش خطاها از اتوماسیون استفاده می‌کنیم؛ اما اتوماسیون احتمال خطای انجام ندادن کاری را افزایش می‌دهد. هیچ سیستم اتوماتیکی نمی‌تواند به همان گستره‌ای که انسان‌ها قادرند واکنش نشان دهند.
 
شبکه‌ها از سخت‌افزار، نرم‌افزار و کابل‌های طولانی تشکیل شده‌اند، بنابراین آن‌ها نیز دچار خطا می‌شوند. هر مکانیسم ایمنی که برای کاهش یک نوع خطا استفاده می‌کنیم، نوع جدیدی از خطا را اضافه می‌کند.
 
پس، با پذیرش این که سیستم‌ها قطعاً دچار خرابی می‌شوند، می‌توانیم واکنش سیستم‌ها به این خرابی‌ها را طراحی کنیم؛ همانطور که مهندسان خودرو مناطق شکست (Crumple Zones) را برای محافظت از سرنشینان طراحی می‌کنند، می‌توانیم حالت‌های شکست ایمنی را ایجاد کنیم که خسارت را محدود کرده و از بقیه سیستم محافظت کنند.

 #TIP-08

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

به محض اینکه صحبت از کاهش هزینه‌ها می‌شود، مدیر پروژه می‌پرسد: «آیا واقعاً به این نیاز داریم؟» و برای «این» هر چیز مهم و ضروری که در سیستم لازم است، جایگزین می‌شود؛ از جمله مجوزهای نرم‌افزاری، سرورهای اضافی، پشتیبان‌گیری‌های خارج از سایت یا منابع برق.
 
در چنین شرایطی، پاسخ درست این است که بگوییم: «بله، به آن نیاز داریم.» اما اکثر اوقات، پاسخ متفاوتی ارائه می‌دهیم. چون به‌عنوان مهندسان، به مصالحه و انتخاب‌های مختلف عادت کرده‌ایم. به همین دلیل به جای پاسخ قاطعانه، شروع به توضیح دادن و توجیه می‌کنیم و معمولاً مدیر بعد از کلمه «خب...» دیگر گوش نمی‌دهد.
 
مشکل اصلی این است که ما کار خود را به‌عنوان مهندسی و حل مسأله می‌بینیم، در حالی که مدیر پروژه آن را به چشم یک مذاکره نگاه می‌کند.
«وقتی مدیر پروژه می‌پرسه "آیا واقعاً به این نیاز داریم؟" به جای توضیح فنی، بگو "بله، بدون این، سیستم سه بار در روز سقوط می‌کنه، مخصوصاً وسط جلسه هیئت مدیره!" گاهی مذاکره یعنی قاطعیت، نه توضیح!

 #TIP-09

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

تعریف دقیق نیازمندی‌ها در معماری نرم‌افزار حیاتی و عباراتی مانند «سریع»، «پاسخگو» یا «قابل گسترش» به خودی خود کافی نیستند؛ زیرا معیاری برای سنجش آن‌ها وجود ندارد. با این حال، کاربران همچنان این ویژگی‌ها را می‌خواهند. نقش معمار این است که این ویژگی‌ها را تا حد امکان فراهم کرده و بین تضادهای احتمالی آن‌ها تعادل ایجاد کند.
 
اگر این نیازها به‌طور مشخص و قابل اندازه‌گیری بیان نشوند، هیچ مبنایی برای پذیرش سیستم توسط کاربران وجود نخواهد داشت و راهنمایی ارزشمندی از مهندسان در حین کار گرفته می‌شود. در نتیجه، معماران باید تلاش کنند این نیازها را با سوالاتی مانند «چقدر؟»، «در چه مدت زمانی؟»، «چند بار؟»، «چقدر سریع؟» و غیره به مقادیر دقیق تبدیل کنند. اگر این اطلاعات در برنامه تجاری سیستم نیست، باید علت آن را جستجو کرد و آن‌ها را دریافت.
 
همچنین باید نیازمندی‌های نامشخص را به‌صورت محدوده‌ای تعریف کرد: حداقل، مطلوب، و حداکثر. اگر این محدوده‌ها مشخص نشوند، یعنی رفتار مورد نظر سیستم به‌درستی درک نشده است. این کار ممکن است وقت‌گیر و هزینه‌بر باشد، اما اگر هیچ‌کس به‌اندازه کافی به عملکرد اهمیت ندهد که هزینه تست‌های عملکرد را بپردازد، احتمالاً عملکرد مهم نیست و می‌توان روی جنبه‌های دیگر تمرکز کرد.
 
برای مثال، نیازمندی‌هایی مثل: «باید به ورودی کاربر در حداکثر ۱۵۰۰ میلی‌ثانیه پاسخ دهد. تحت بار عادی (تعریف شده به‌عنوان...) زمان پاسخگویی بین ۷۵۰ تا ۱۲۵۰ میلی‌ثانیه باشد. پاسخگویی زیر ۵۰۰ میلی‌ثانیه توسط کاربر قابل تشخیص نیست، بنابراین برای کمتر از این مقدار هزینه نخواهیم کرد»، نیازمندی‌های واقعی هستند.  ‏"نیازمندی‌هایی مثل 'سریع' و 'قابل گسترش' بدون معیار مشخص بی‌فایده‌اند. برای تعریف درست، اعداد و محدوده‌ها را مشخص کنید: چقدر سریع؟ چند کاربر؟ چه زمانی؟ اگر برای تست عملکرد هزینه نمی‌شود، شاید اصلاً مهم نباشد."
#TIP-10

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

مجموعه مقالات سال ۲۰۲۳ آقای Alex Xu  درباره سیستم دیزاین. ایشون یکی از شناخته‌شده‌ترین آدم‌ها در مارکت سیستم دیزاینه و کتابهاش بست‌سلرن!

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

در یکی دو هفته آینده یک مینی پلی‌لیست در مورد ضرورت و مفاهیم بنیادین Observability در دنیای مدرن نرم‌افزار با تمرکز بر OpenTelemetryخواهیم داشت

* پلی‌لیست‌های باز قبلی رو هم به مرور آپدیت خواهم کرد. بویژه گو و پستگرس.


© @microfrontend_ir

@IIIllIlll زحمت کشیدن یک ریپو خوب برای آموزش او ار ام جنگو ساختن


https://github.com/rz-k/django-orm-tutorial

Observability در فضای Cloud Native
به زبان ساده، Observability توانایی مشاهده و تحلیل وضعیت داخلی یک سیستم از طریق داده‌هایی است که آن سیستم تولید می‌کند. در فضای Cloud Native، سیستم‌ها از مجموعه‌ای از میکروسرویس‌ها و زیرساخت‌های پویا تشکیل شده‌اند که نیاز به نظارت دقیق و لحظه‌ای دارند. Observability به شما کمک می‌کند نه تنها بدانید چه چیزی اشتباه است، بلکه دلیل وقوع آن را نیز پیدا کنید.

تفاوت Observability و Monitoring
در حالی که Monitoring برای جمع‌آوری و مشاهده معیارهای از پیش تعریف‌شده (مثل استفاده از CPU یا تعداد درخواست‌ها) طراحی شده است، Observability بر قابلیت مشاهده و تحلیل داده‌های خام برای کشف الگوهای جدید تمرکز دارد. این مفهوم به تیم‌ها اجازه می‌دهد به جای پیش‌بینی همه سناریوها، در زمان وقوع مشکلات داده‌های لازم را جمع‌آوری و تحلیل کنند.


Video Link: https://youtu.be/UK71422S-rY

PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBy6YIfteatuV50ezQODRsEQ
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

سوال:
یک جدول حجیم دارید و ۱۰ ایندکس روش دارید، یک رکورد اینسرت می‌کنید و «بلافاصله» همون رو کوئری میزنید که برگرده.
۱. آیا رکورد برمیگرده؟
۲.‌در دیتابیس های مختلف مثلا مای‌اس‌کیوال و پستگرس رفتار یک شکل است؟
۳. اگر درج و کوئیری در یک ترنزکشن اتفاق بیافتد رفتار متفاوت می‌شود؟


〰️〰️〰️〰️〰️〰️
© @microfrontend_ir

در قسمت اول از پلی لیست Observability Engineering پیش از آنکه وارد مفاهیم اصلی شویم از طریق OpenTelemetry Demo Project سعی کردم یک Big Picture از آنچه قرار است به آن برسیم ارایه کنم. پروژه دمو اپن تلمتری یک پروژه ساده ولی خوش ساخت با استفاده از معماری میکرو سرویس است که الزامات مهم Observability در آن لحاظ شده است.

** یلدا مبارک :)

Video Link: https://youtu.be/s1YhTCYwbgs

PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBy6YIfteatuV50ezQODRsEQ
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir